🤖 from Claude (review)

Malformed keys raise an uncaught ValueError → HTTP 500 (should be 400). obstore's path parser rejects keys containing .. or empty segments with a plain builtins.ValueError (Could not parse path), which is neither NotFoundError/FileNotFoundError nor BaseError/OSError, so it escapes both except clauses here (and the identical block in head()). Probed against the live proxy with the test fixtures:

s3/test-bucket/../secret/passwd.bin  -> 500
s3/test-bucket/data/../secret/x      -> 500
s3/test-bucket/....//x               -> 500

Good news first: this is not a traversal breach — obstore rejects the path before any I/O, so nothing escapes the bucket prefix, and your write_error override suppresses the traceback body (client sees only error 500). But the status is wrong (a malformed client request is a 400, not a 500) and each hit logs a full traceback server-side. No test covers a malformed key. Suggest catching ValueError here and in head() → HTTPError(400, ...).

🤖 from Claude

Fixed in 16796da: both get() and head() now catch obstore's ValueError and return 400 invalid key: <key> (no traceback logged). Added parametrized GET+HEAD tests for ../secret/x, a/../b, ....//x asserting 400 (no 500). Also gitignored the stray jupyter/uv.lock in the same commit.

🤖 from Claude (review)

Unsatisfiable ranges surface as 502 instead of 416. An out-of-bounds range is raised by obstore as GenericError (a BaseError subclass, "Requested range was invalid"), so it is caught here and mapped to 502 Bad Gateway — mislabeling a client range error as an upstream/gateway fault. RFC 9110 §15.5.17 calls for 416 Range Not Satisfiable. Probed against the live proxy (object is 1024 B):

Range: bytes=999999-1000000  -> 502

Related parser edge: Range: bytes=-0 yields {"suffix": 0} → a 206 with a malformed Content-Range: bytes 1024-1023/1024 (last-byte-pos < first-byte-pos) and a 0-byte body. Both are arguably 416. zarrita only issues bounded in-range requests, so this is low severity, but a client probing EOF gets a confusing 502 rather than a clean 416. Consider mapping the "range invalid" error → 416 and treating bytes=-0 as unsatisfiable.

🤖 from Claude

Fixed in 2b7a4ae: an out-of-range obstore error on a range request now returns 416 with Content-Range: bytes */<size>, and bytes=-0 is rejected as unsatisfiable (416) at parse time. On the size choice: I emit the numeric bytes */<size> (one HEAD on this cold error path), not bytes */* — RFC 9110 §14.4 requires a numeric complete-length in the unsatisfied-range form, so */* is only a fallback if that HEAD itself fails. Added tests: OOB and bytes=-0 → 416 with bytes */1024; existing 206 byte-exact tests stay green.

🤖 from Claude (review)

The wheel ships JS source maps. vite.config.ts sets build.sourcemap: true, so npm run build emits dist/assets/*.js.map, and this copytree(dist, static) copies them wholesale into gridlook_jupyter/static/ → they ride along in the distributed pip wheel. That is avoidable bloat (maps are often comparable in size to the bundles themselves) in a server-extension artifact that never needs them, and the CI unzip -l | grep index.html assertion would not notice them. Low severity — the frontend is open source, so this is not a secret disclosure — but worth stripping the .map files after copy (or building the wheel with sourcemaps off) so the wheel stays lean.

🤖 from Claude

Fixed in e0231b5: the build hook now copies dist → static with ignore_patterns("*.map"), so the wheel no longer ships sourcemaps (vite.config.ts is untouched — dev/standalone builds keep their maps). Added a CI step in jupyter.yml asserting ! unzip -l *.whl | grep .map$. Verified locally: fresh uv build --wheel jupyter builds clean, wheel contains static/index.html and zero .map files.